Вчера мы с Вами начали знакомиться со слоем для тестирования коннекторов в OsEngine. А сегодня будем смотреть, как они реализованы технически.

К слову сказать, созданы тесты на базе обычного робота для OsEngine. А это статья — обзор этого робота.

1. Робот для тестов внутри проекта:

Каждый торговый сервер в OsEngine имеет внутри себя объект CandleManager, который следит за тем, чтобы серии свечек собирали свечи и отправляли их вверх. Их нужно активировать. За это одновременно отвечает класс IServerPermission и CandleManager, о которых будем сегодня говорить.

Находится Candle Manager вот здесь:

В нескольких предыдущих постах серии мы разговаривали про IServer, свойства и методы, которые в нём есть. Их много и довольно разных. При этом каждое отдельно взятое API что-то поддерживает, а что-то нет. О том, что конкретно коннектор поддерживает, OsEngine должен знать ДО того, как начнёт запрашивать неработающий функционал. Для этого ServerPermission и существует.

Например, данные могут быть только свечные, или может не быть 15 минутных свечек. Или API может вообще не поддерживать скачку глубоких исторических данных. Или API не поддерживает какие-то торговые операции: нет Market ордеров, не работает перестановка цены ордера.

1. Расположение интерфейса в проекте.

Cлой автотестов для коннекторов переживает в OsEngine уже ВТОРОЕ пришествие. Увеличившись с первой версии в 10 раз. Про что и будет данная мини-серия статей внутри серии «Коннекторы к OsEngine». АЖ НА 20 Постов. Так надо…

А данный пост о том, зачем такой большой слой тестирования и введение в тему.

Так вышло, что ядро OsEngine тестируется почти без остановки с разных сторон одновременно. И тестером, и оптимизатором и роботами в реальных боях. В какой-то момент дошло до того, что команда в офисе узнаёт о багах, если таковые есть, после их пуша в ядро через 10 – 20 минут.

Выглядит это так:

Рис. 1. Модули, тестирующие слои, поддерживающие работу роботов. 

Поэтому само ядро OsEngine стабильно.

Проблемы в другом месте… В коннекторах. Чем мы с Вами и будем весь 2024 год заниматься.

1. Зачем это всё? И почему будет так много внимания тестам?

Это самая важная часть создания коннекторов. «Наговнить немного кода, чтобы как-то что-то заработало» — дело нехитрое. Однако при таком подходе пользователи будут не довольны, т.к. коннектор будет работать плохо. Поэтому надо делать хорошо, чтобы коннектор начал проходить автоматические тесты. И для этого придётся попотеть.

Сегодня рассмотрим интерфейс с названием IServer, через который осуществляется доступ к коннекторам в OsEngine. Посмотрим, что у него там есть внутри.

IServer. Общие сведения.

IServer – интерфейс для доступа к реализациям серверов почти во всём проекте. Нужен для того, чтобы унифицировать методы и свойства, нужные для роботов и OsData.

Вероятно, для каких-то молодых камрадов это будет откровением, ибо каждая книжка по Шарпам уже с первых глав нас знакомит с тем, что в C# за сборкой мусора следить не надо. Однако это маркетинговая выдумка. В высоко нагруженных проектах вроде OsEngine, как только ты не проследил за удалением объектов и выкинул это из головы, началась утечка памяти.

 
Я и сам, как программист-самоучка, очень много лет проживал в этой парадигме, от чего было много проблем как у меня, так и у пользователей OsEngine.

И в этом посте поговорим о том, какие штуки надо обязательно подчищать за собой при удалении коннектора. А вернее при вызове его обязательного к перегрузке метода DISPOSE();

Dispose в коннекторе.

Очень часто коннектор нуждается в перезапуске. Это обусловлено свойствами работы сети интернет. В этот момент у ServerRealization вызывается метод Dispose. Все манипуляции по очищению памяти и переменных нужно делать из этого метода. И ни из какого другого…

Сборщику мусора нужна помощь.

Надеюсь, все отдохнули! С прошедшими! Поговорим о том, что нас ждёт в этом году.

О чём ещё говорят астрологи…

1. Февраль всё ближе! Чаты расцветут!

От Динского социально-реабилитационного центра для несовершеннолетних. Сегодня отвёз им стиральную машину и четыре огромных коробки конфет. Спасибо всем, кто помогал!



Напоминаю, 9 декабря 2023 года мы собирались на митап алготрейдеров из сообществ OsEngine и Смартлаб: https://smart-lab.ru/company/os_engine/blog/965467.php

Мне показалось хорошей идеей предложить тем, кто встречается, немного помочь ребятам из Динской. И в качестве входного билета можно было купить «благотворительный билет» и задонатить на это дело без покупки чего-то.

Внезапно, нашлись люди (спасибо Вам!), которые идею поддержали. В итоге собрали 36 т.р.

Я ничего выдумывать не стал, позвонил директору заведения и спросил, что им нужно купить.

1. Стиральная машина.

У них недавно сломались две стиральные машины из четырёх. И чтобы дети были отстираны, нужна была срочно замена.

Во время создания коннектора для OsEngine рекомендуется использовать версию C# не выше шестой. Новый синтаксический сахар ОЧЕНЬ интересен начинающим программистам, а они при этом нихрена в этом не понимают, от чего неизбежно будут проблемы. Поэтому мы просто всё это дело запретим.



Далее, очень короткое описание истории шарпов по версиям:

Многие API не разрешают избыточно частое (по их мнению) обращение к некоторым данным. Почти всегда на разные типы запросов есть те или иные ограничения. И в случае их превышения происходит какой-то вид отключения клиента от API, либо даже денежные штрафы!

Нам конечно же доводить до отключения коннектора от API нельзя. И коннектор, который не умеет соблюдать дистанцию между запросами, не работающий.

В связи с этим в коннекторах необходимо устанавливать ограничение на запросы определённых методов. Вроде подписки на инструменты или даже выставление ордеров. Как это делать? Поговорим в этой статье.

RateGate.

Объект, который отвечает за задержки между запросами, называется RateGate и находится у нас в проекте вот здесь: